With the recent "PR1.2" firmware upgrade of Nokia N900, a new feature was enabled in the browser - WebGL. WebGL is cool and scary. The cool part is that it is a chance to bring lots of games to to Linux users. The screenshot is from Match3D, a 3D tic-tac-toe game.

The best way to get started is with the Learning webgl tutorial. Passing through the lessons, some are clearly featuring buggy graphics. I don't know if the website, N900 browser or the OpenGL ES driver is being buggy. Which brings the scary part of WebGL - not only does one need to deal with buggy browsers, one has to deal with buggy 3D hardware/drivers! WebGL is still very much work in progress, and on N900 the webGL is rather an "easter egg" than a proper feature. For example the 3D graphics from the GPU does an extra roundtrip via CPU before appearing on the screen.

Other WebGL resources are planet WebGL for following blogs about WebGL, the Khronos Demo repository and more demos can be found at CubicVR site. The last CubicVR demos feature another scary new browser feature (not yet supported on N900) - audio processing in JavaScript.

Jep, I'm coming. I bought flight tickets from Icelandair just weeks before Eyjafjallaj kull changed from a little known volcano to something everyone knows (but probably can't spell if asked...). The volcano seems to have settled, but at some point I was really happy the ticket was paid with credit card, and at least I'd get my money back. After debconf we plan to travel around NY and nearby, but the accomodation appears to annoyingly expensive, I guess due august being the high season for travel...

In other news it is also possible that I'll visit aKademy 2010 in Tampere, Finland this year.

[The following story is fictional and does not depict any actual person or event, just like in Law & Order.] James filed an RC bug on a package, complaining that it attempted to execute an illegal instruction on a Netwinder, running Linux 2.6.xx. This was sort of an ironic hipster tribute to the olden times when buildd admins would actually do their jobs, keeping chroots clean and current, reviewing buildd logs, and filing FTBFS bugs where appropriate, except that he didn't actually do any of those things. 18 minutes later, Aurelien replied, asking for more information in order to debug the problem. Teh-oh said James, but nobody could hear him because he was talking to his Raggedy Ann doll. Stephen suggested that Aurelien contact Vince or Steve to get access to different Netwinders, and Aurelien tried to reproduce the problem on other ARM machines unsuccessfully. Could you tell me the exact kernel version on this Netwinder, and the one on europa, which seems to have the same problem? Aurelien asked James. Aaagh, they're trying to steal my precious bodily fluids! hissed James, but nobody could hear him because he was talking to his inflatable astronut. Also, the contents of /proc/cpuinfo would be nice. Aurelien added. We hates them, Clive Oven! James announced, but nobody could hear him because he was talking to his EASY-BAKE REAL MEAL Oven. The Netwinder you were talking about is europa, wasn't it? Could you tell us the kernel versions on europa and elara? There's no problem on other Netwinders, so it's probably a kernel issue. THE MARTIANS ARE COMING! James cried, but nobody could hear him because he was talking to a small band of subservient deaf-mute milkmen. It's been more than a week since this bug has been filed, and there has been no useful information provided at all. Can anybody help? asked Peter. HELLO. IS THIS THING ON? Could you have the elementary courtesy to follow up to the bugs you report? asked Pierre. Bromeliads.. I'll buy you some bromeliads, James muttered, but no one could hear him because he was talking to his ficus plant. Lo c looked around, slipped into a cave, sprinted through a maze of tunnels, and sped in a small nuclear-powered submarine to James's secret undersea lair. Rapping on the bulkhead three times, he uttered the code phrase and James let him in. After a conversation that took place strictly through pantomime, Lo c departed and James said, For fuck's sake, but no one could hear him because he was talking to a broken sonar antenna. Yo, James is busy, but he said that it's okay to downgrade the bug since it's not a problem with other Netwinders, reported Lo c. I never said that! I don't even know who that guy is! I'm going to convert him into a kangaroo! James sang, but no one could hear him since he was alone on a beach in Normandy. A month later, Riku wrote to Woody, Hey, we have this bug. Could you take a look? Sure, replied Woody, and he gave Aurelien access, and Aurelien debugged the problem in under an hour. Now everyone knows that europa and elara were running Linux 2.6.11. This is a breach of national security! declared James, but nobody could hear him because he was talking to the crushed skull of a kitten who had recently been sunning himself.

Techcrunch wrote recently an enlightening article about Scam ads in social games.

Irony is the techcrunch article itself showing scam banners as well:

Turns out TAP is starting to fly Lisbon - Helsinki this summer, and thus offers cheapest flights from Finland to near debconf (at least with my ticket searching magic skill level). And a (night) train from Lisbon to Madrid goes via C ceres. It appears one can't order the train tickets yet (from renfe.es), the reserving opens 60 days beforehand.

I received a SheevaPlug this week, an intriguing device that packs incredible power and functionality into a tiny package. As many of you know, I've been doing a lot of work on Debian for the Linksys NSLU2 in the last few years. The NSLU2 is a key reason why ARM has become the third most popular architecture in Debian (after 32 and 64 bit x86), and I believe a main reason is that the NSLU2 is so incredibly cheap. At a price under $100, most people don't think too long and simply buy a device and do something cool with it. The SheevaPlug is being offered at the same price range but offers considerably more. Riku Voipio asked the right question: "What would you do with something approximately 10x more powerful with same prize/size range?" I believe the SheevaPlug is a killer replacement for the NSLU2 and here's why:

• Marvell Kirkwood 6281 CPU at 1.2 GHz with 256 KB L2 cache (compared to a 266 MHz CPU)
• 512 MB RAM (compared to lousy 32 MB)
• 512 MB flash, enough for a basic Debian installation (compared to 8 MB)
• Gigabit Ethernet (compared to 100 Mb) and no proprietary microcode required
• 1x USB and 1x SD (compared to 2x USB: the only advantage the NSLU2 has)
• ... and finally: mini-USB with serial console and JTAG: while Debian on the NSLU2 works well and is stable, we regularly had users whose system would no longer boot and there was no good way to figure out why. The serial console on the SheevaPlug actually allows users to figure out what's going on.

I'm incredibly excited about the SheevaPlug and the first thing I did was to take the device apart and look at the inside. The results can be found in the SheevaPlug image gallery. My next project will be slightly more productive: porting Debian. As I see it, we should support the following three installation variants for the SheevaPlug:

• To an external USB drive or stick.
• To an SD card.
• To the 512 MB flash memory on the device.

The first two should be relatively straight forward, but of course installing to the internal flash memory is particularly interesting given that 512 MB (plus compression) is enough for a basic installation of Debian. Unfortunately, installations to MTD flash are currently not supported in the Debian installer but I hope we can find a volunteer who wants to implement this functionality. My next steps are to put a kernel for the SheevaPlug into the archive and to get a basic installation going. From there we can look at more sophisticated installation options and other functionality.

popcon lists approximately 1000 arm/armel Debian installations. There is also listed 864 installations of nslu2-utils, letting us estimate that approximately 85% of debian/arm(el) installations are Linksys nslu2's. It is nicked sympathetically as "The Slug", which pretty accurately describes the performance of nslu2. Still, people have found absolutely amazing amount of ways to use their slugs. What would you do with something approximately 10x more powerful with same prize/size range?

Enter the Marvell SheevaPlug

  What   Slug      SheevaPlug  
  CPU    266Mhz     1.2Ghz      
  Cache  32KB       32+256KB    
  Flash  8MB        512MB       
  MEM    32MB       512MB       
  Net    100Mb      1Gb         

And that's not everything - SheevaPlug comes with SDIO slot and miniusb to be used as a serial console (and JTAG). No soldering needed for hacking.

Some more details on the LinuxDevices article.

For those of you who think that has one port too few of something, or don't like the wall-wart design, Other devices based on kirkwood SoC (which SheevaPlug is based on) are on the way from various ODM/OEM houses.

In practice for me, this that I finally had to setup stable buildd chroots for armel (ya!). This makes the Debian the first general purpose distribution to release with a ARM EABI port. Thanks for everyone who made this happen, even when the naysayers were claiming that Debian would be too inflexible for another arm port! The list of people who made this possible is simply too long to include in a blog post, and I'm afraid I would still forget someone...

For squeeze, I hope we can keep the name as the release theme and squeeze minimal Debian install into smaller disk and memory than what it takes with lenny :) For more specific squeeze plans on the armel port, we are looking at least into providing optimized versions of various libs (using HWCAP feature) and extending the amount of hardware supported. Not ARM-related directly, but I'd really like to see #206684 fixed finally.

Here s for the second installment of my review of this past year s Summer of Code at Debian. See the previous part here: Debian Summer of Code 08 : Where are they now (part 1/3). I apologize for being so late at getting this second part out but I have been very busy. Still, I ll get the last part out before FOSDEM. Those of you who ever had to write a Java compiler (ok, Java subset, but the OOP part was here ) in brainfucking Ada will understand what I went through working on two of my most loathed languages. Debian NAS, improve support of Debian on NAS devices Presentation There is a large range of inexpensive Network storage devices available on the market. For some of them, such as Linksys NSLU-2 and Thecus N2100, we have added support, but there is many many more devices we could support. For this summer we look forward at supporting multiple Marvell Orion based devices (as outlined in Martin Michlmayr s talk Running Debian on Inexpensive Network Storage Devices), such as Revogear Kuro Box Pro, Buffalo Linkstation, QNAP TS-109+, If you don t have old computers lying around to turn into NAS servers, you need to sleep at night without the soothing sound of computer fans or if you actually pay your own electricity bill, you might want to have a look at standalone NAS devices. They re cheap and can be made vastly more capable by slapping a Debian on it. If you ever heard of DD-WRT, you know the spirit. The project was mentored by Riku Voipio, with help from Martin Michlmayr. The project proposal (sorry, Google cache) was introduced by Martin, who did a presentation about it the previous year at FOSDEM. Student Per Andersson was a 24 year old student working towards a MSc in computer science at Chalmers University of Technology in Sweden. He had been looking for ways to join Debian but with school still being priority one, he didn t find time to dive in. Result This project was successful. The Kurobox Pro is now supported and several useful tools were packaged to make life easier with these NAS devices. Martin Michlmayer is still working on Debian NAS related stuff. Per was happy to be invited to the Emdebian work session in Extremadura and has been active within debian, maintaining the packages he created during the Summer of Code. Cran2deb, generate Debian packages from R packages Presentation GNU R has become the preeminent platform for computing with data . The CRAN archives contain over 1300 source packages of very high-quality, and BioConductor has again almost as many focuses on bioinformatics. We want more of these in Debian, and going beyond the 50+ packages we currently have suggests more scripting and automation. R is a pretty big among statisticians and all of them they wasted no time writing their own package to work on particular research subject. It s a lot like Perl with CPAN or LaTeX with CTAN. It s always a pain to discovery that a particular R package is not wihtin Debian and having to resort to unmanaged installation of said packages. The project was mentored by Dirk Eddelbuetel. The project proposal (which is nowhere to be found but seemed to be good) was introduced by Dirk, along with another proposal he did for R. Student Charles Blundell is a research student at.. hum.. didn t do my homework about that. Anyway, you can find him around R related projects. Result This project was successful. Cran2deb is happilly turning more than 1400 of the ~1500 CRAN R packages, all with correct dependencies. The work has since been moved to R-Forge. It s working, we re almost there. We just need it to be polished and we ll get a whole bunch of new packages into Debian. Charles pinged me about the status of Cran2Deb after the previous post. He admits that he hasn t done much about cran2deb recently because of his new position as a research student but hopes to commit again to it soon. I do encourage him to get these R packages into Debian. I had to manually install some packages myself when I had to use R for school because they weren t into Debian and it s not pretty. Mergemaster, interactively merge changes in configuration files Presentation FreeBSD has a shellscript called mergemaster which is used to interactively merge changes in configuration files, based on 3-way diffs. Debian s approach to configuration file differences is much more primitive: either keep the original file, or blow it away (including all local changes) and use the Debian-provided file. It would be nice to get a system such as mergemaster into Debian. Important is to remember that Debian contains two often-used configuration file management systems: ucf, and conffiles; porting mergemaster in such a way that it will be used in both cases would be great. The handling of configuration files during upgrades has always been a little.. brutal, with the user being asked at gunpoint to make a good decision, lest the upgrade won t continue or configuration files get borked (ever tried automerging nagios configuration files?). Having a less stressful upgrade experience is a good thing since the point of Debian is to make package management a stressless thing. The project was mentored by, hum, Manoj Srivastava. I have no idea who came up at first with the proposal. UPDATE: Wouter Verhelst mailed to say that he made the original proposal. Student Max Wiehle was a physics student at the University of Heidelberg. He did a Summer of Code stint (Archive.org copy..) as a student for Beagle Project in 2006 which, I suppose, was successful. He s been active in the past with Gnome and desktop related projects. Result This project was somewhat successful. He posted an update one month into the program with repositories with code to test. Last commit to the mergecf branch of project was September 19th but it was never merged in. According to Steve McIntyre, it s dead, Jim. I couldn t find any further public involvement of Max within Debian. PAS NSS Debian Installer, improve support of PAM and NSS at install-time Presentation It would be very important for the Debian allowing the user to configure additional PAM and NSS modules (eg. LDAP, NIS) during the installation process inside the Debian Installer. To do this, we have to provide tools and helpers to modify /etc/nsswitch.conf and /etc/pam.d/common-*, as well as changing the maintainer scripts for the packages libpam-* and libnss-* to apply the required changes at install time using debconf and these helpers. To be honest, I will probably never use this. I don t do that many coordinated installs in the same place to warrant doing funny authentication with PAM and NSS, and if I did, I would probably use a more elaborate tool to personalize the install, like FAI. On the other hand, I can see the appeal of being done with authentication mechanisms before the first boot. The project was mentored by Fabio Tranchitella. The proposal came from the student. Student Juan Luis Belmonte was a computer science student. He worked in a couple of companies in the area of Sarragossa. He is now founding debug_mode=ON. Result This was quite a disappointement after seemingly good work. Although Juan was satisfied with the project, the PAM package maintainer (Steve Vorlon Langasek) was not. He was never asked about this project (but didn t intervene timely either when the accepted projects were announced though). In his words, it was the wrong solution to the problem . You can find his lenghty rationale on the wontfix bug report that resulted from the project. It really was a problem of communication with the Debian developpers since Juan could certainly have done the right work if pointed to it. Juan didn t ask thoroughly for existing work and Steve didn t publicize his (enough). That s all for now. The information is quite fragmented I admit. Most of it was pulled from Google, mailing lists, commit logs, blogs, whatever. If some projects are lacking in information here, it s because I couldn t find it readily (which is an issue in itself!). In my next post, I ll try to give a student point of view of the Summer of Code in general, and more specifically, at Debian. It will be post 2.5/3 since it s getting a little longer than I planned. Release early, release often, as the say.
If you re a student or a mentor mentioned above, feel free to fill any of the blanks in my report. It s much appreciated. You re not a student or mentor mentioned above and have an opinion on how to improve the next Debian Summer of Code ? Feel free to comment.

Sorry Bastian, but that marthyrdon thing doesn't work. Debian has no shortage of talkers, GR-proposers, etc. We have shortage of people of actually doing stuff. Therefor it's only fair that people not bothering fixing bugs get criticized too. And not to mention that there is enough RC bugs open that you could *easily* fix one of them before making another blog post.

This post has been brought to you by fixing #508781 and #496104. (Can I has a meme plz?)

ps, that said, pretending reaching 0 RC bugs means we have a perfect release is delusional. Bugs are found at constant rate. If we fixed bugs faster and reached 0 RC bugs a month a go, the released lenny would now have all the RC bugs found during this month. Therefor it would make much more sense to align the release schedule based on something else, such as d-i schedule and fix any RC bugs left at that point with stable release updates. update: As noted by Dato, the release update essentially says the same.

As the continued freeze of lenny has driven lots of interesting uploads to experimental, it was finally time to setup a armel buildd for lenny. It' now approximately half away done, and with the current rate it should be building the last package of the queue (openoffice) in the end of this week.

After a brief look at the market, I decided to keep using my sturdy X40. Looking at what could be done to improve the 4 years old workhorse, three things came to mind:

* new battery (old one dies in 45min, new one lasts easily 5+h)
* replace the hard drive (preemptively before it breaks)
* more ram (from 512MB -> 1.5G)



The only one worth detailing is the hard drive upgrade, since I decided to go SSD. less moving parts, less heat, less power consumption. I followed the Thinkwiki CompactFlash boot howto. This basically involves getting a CF-IDE adapter (from ebay, around $5) and any CF card. The first CF-IDE adapter $2.99, but it didn't work. After some research it was concluded that the SMT soldering was bad. The second adapter bought worked fine, and as a bonus the dimensions match the X40 HD perfecty:

In order to minimize writing to flash:

* Make sure root filesystem is mounted noatime,nodiratime (see /etc/fstab)
* make /tmp a tmpfs partition
* disable swap
* more tips can been seen at Linux on Flash guide

Generally I'm very happy with the results of the upgrade. X40 is now most of the time completly silent, without the spinning and clicking HD. Fan turns on less often than previously. The cheapo compactflash is fast enough on reading, and the REALLY slow write speed is usually not a problem thanks to the loads of RAM. Ofcourse, the exception is when a application uses fsync() ... which leads to.

FIREFOX SUCKS GOAT BALLS WHEN RAN FROM A SLOW SSD

Seriously. It's like watching snail cross a tarpit. That's what happens when you fsync() a 30MB places.sqlite on a 6MB/s write speed flash media every fucking time a page has finished loading (and seeming every now and then too). Now here's a really simple workaround: make ~/.mozilla tmpfs and rsync it to/from a backup dir every time you log in/out.

* /etc/fstab: tmpfs /home/user/.mozilla tmpfs size=100m,user 0 0
* and two helper scripts:

aardvark:~$ cat bin/mozilla-mount
#!/bin/sh
mount /home/$USER/.mozilla
rsync -av /home/$USER/.mozilla-safe/ /home/$USER/.mozilla/
aardvark:~$ cat bin/mozilla-umount
#!/bin/sh
rsync -av /home/$USER/.mozilla/ /home/$USER/.mozilla-safe/
umount /home/$USER/.mozilla

It does what mozilla should be doing in the first place - write to temporary files when running and on exit synchronize to the real database and fsync(). With this hack, suddenly the web browser UI doesn't freeze every time a page has finished loading.

You'll also want to disable the urlclassifier anti-forgery tool, which can grow to a over 50MB sqlite database which also gets fsynced all the time...

Per Andersson ported the Debian installer to the Kurobox Pro this summer as part of a Google Summer of Code project. Along with Riku Voipio, I acted as Per's mentor and gave him advice while he was trying to figure out all the details that were needed to get Debian running on the device. Since I spent the summer in Israel and didn't have my Kurobox Pro with me, I never performed an installation on my own though. Yesterday I finally found time to play with my Kurobox Pro. Per did a great job and the installation worked without any problems. I also investigated how the recovery mode works and added various new information to my Debian on the Kurobox Pro pages. The Kurobox Pro seems like a nice machine, but I hope we'll add full support for the Linkstation Pro and Live soon since these devices are much more easily available. It shouldn't take too much work since these devices are quite similar to the Kurobox Pro.

I actually think it's a bit of an insult if people think of Motorola's EZX or MAGX (and now Android) phones as "Linux phones". Because all the freedoms of Linux (writing native applications against native Linux APIs that Linux developers know and love, being able to do Linux [kernel] development) are stripped.

-
http://laforge.gnumonks.org/weblog/2008/10/23/#20081023-android">
http://laforge.gnumonks.org/weblog/2008/10/23/#20081023-android">
http://laforge.gnumonks.org/weblog/2008/10/23/#20081023-android">Harald Welte

This is something that has worried me too for quite a while. For years we have now had Linux phones available in form or another (well, mostly in far away countries you happen not to be at). Yet with the exception of openmoko none of them allow native application development. Yet all the same time you can go to the nearest phone shop and grab HTC windows CE phone or a Nokia Symbian phone, which actually give you the freedom to writing and running your own software on them.

Now we have the situation that HTC's most locked device* is their only Linux device - The Android G1.

Incidentally, you can install Debian/armel on T-mobile G1, but only until Google engineers manage to fix the hole that gives you r00t.

*The only one that doesn't allow native app development.

What we are having here is a quite non-typical ARM based motherboard. It features a pre-production version of Marvell 78x00 series ARM SoC, clocked at 1GHz. It features multiple on-board sata and gigE connectors, as well as pci-e slots and DDR2 ram slots. Fairly "meh" in x86 world, but on the ARM world most systems are designed mainly for low power consumption, tiny size and low cost. Which, while creating allows creating many exciting devices, makes finding meaty buildd's tricky. When we intruduced armel port, the security people rose the concern that arm buildd's are too slow. Especially from the security Point of view, where getting security fixes out fast is important - every second of waiting for security builds to finish someone could be exploited!

Luckily, some people from Marvell had heard about our need and arranged to donate a developer board for us!

So far, the build speed improvement, compared to our current (Thecus N2100) buildd's is very promising. When looking at build times of some slow-building packages which likely will see security uploads:

Package     Thecus   MV78100   HPPA    MIPS
linux-2.6   39h      11h       6h      17h
webkit      17h      5h        3h      4h
qt4-x11     59h      17h       7h      13h
xulrunner   14h      4h        1.5h    3h

We see that with a Marvell board we are more in the line with other architectures. And the production hardware is going to be even faster! There is a dual-core version as well, but it's not SMP. Both cores are independent, and would basically both run their own Linux image. If manage to find a easy way to implement and manage that, we could run two theoretically run two independent buildd instances on the same board.

See the Linux Devices article for more details about the MV78x00 in general.

In an hour the online part of this combined embedded+fai meeting in Badajoz in Extremadura, Spain, will sadly be over, but the sadness will hopefully be compensated by good food (yes, the food at the last dinner was great) and more fun! To me it were three intensive days (plus some two half days of intense travelling) which were really productive. This post is a summary of what I did here, to document how useful these meetings are. I'm only one person out of 18, who did some Debian work here, much more stuff was done, most of it I probably didnt even notice, as 14 people where working on embedded stuff, which I mostly ignored... ;-) That said, I think it was still very nice to have this meeting together, a.) because I'm quite interested in embedded stuff and b.) because the embedded crowd is a fun one to hang around with!

Right now I'm quite tired so that I dont fully remember what I have done on the first day :) It included uploading the DebConf7 mpeg videos which will now be used by Miguel Gea to create DVDs from those, so that he gets familar with the toolchain, so that he then can do the DebConf8 DVDs once those videos are (fully) ready. That will still take some time though, but hopefully not too long.

Unlike DebConf8 I also brought my fancy new fonera2 with me, in the hope to give it to someone to work on emdebian support for it. This is quite a longer road, as currently uclibc is not part of Debian, but thats only one step in this puzzle. Much to my joy Per Andersson took the opportunity to play with it and now took it home with him to document how to run Debian on it. I'm looking forward to see progress on this in the future ;-) Update: uclibc support is only needed for running Debian from the 4mb flash it has. But since it also has an usbport one can attach some storage there and run a full Debian system, just like on the nslug, which also has 32mb of RAM.

Unfortunatly I basically forgot about the FSG-3 I also took with me (which was for good reasons, one the second and third day I mostly did FAI work), but then I remembered 90min before the end, which was really too late. Narf. But Riku had a short look at it and told me one thing I didn't knew before: (at least) arm(el) kernels need to have the cpu id set in the kernel and the debian kernels don't have that, as they are build for more than one cpu type, so one has to prepend an arm assembler code instruction before running the kernel... I'm curious to do this soon :-)

But I have more hardware news to tell: C sar G mez Mart n (thanks for organizing this meeting, too!!!1) gave me back my OLPC laptop which I borrowed to him quite some time ago, so he could use it for a talk he gave at a university in Extremadura, so now I finally could give Andres Salomon new debian image for the XO a try. It was really nice to finally see a nice Debian gnome desktop on the device :-)

Today the FAI group, that was Sebastian, Michael, Thomas and me, also took a break to visit the Alcazaba de Badajoz (built around 1100, so roughly 900 years ago) which is an amazing building (thats why I linked to the spanish wikipedia entry as it has nicer pictures), from where you can see most of the city. I've been to Badajoz at least three times now and I'm really glad I finally did that, it's only 5min away from the office where the meeting was held and I highly recommend it to anyone going here.

Oh, and last and definitly not least I did a lot of work on FAI too. Besides discussing stuff which will hit planet after I posted this (hah! Michael already posted it, though without proper credit, so I will do a repost) I mostly reviewed changes and patches and discussed bugs, I didn't develop many patches myself (well, except one for the changelog..) but I've read every change at least twice, once as a commit msg and once in a full review. Plus many patches I read more often... all in all I think FAI is now in an great shape for lenny (which was the only thing we worked on during the weekend, we discussed some future plans, but work was only done for lenny), except that we want to another upload (with only documentation changes) after the upcoming one (which has quite some documentation changes already, but also some RC+important and some trivial bugfixes).

As you might have guessed, I started this entry on saturday and am finishing it now. According to the topic of the #extremadura2008 channel, which we created to coordinate between the groups, we also fixed 7 RC bugs (or 8? one should really document the bug numbers and not the number of bugs..) affecting lenny and 3 more which are only relevant to sid. Which is not as many as I would have liked to be fixed, but then, it wasn't a ("traditional") bug squashing party either. Which makes me wonder, are there any planned in the coming weeks?

So all in all I think this meeting was really very productive. Plus, I also enjoyed a special half an hour of real holidays: on saturday we had to leave lunch without having a chance to have a coffee afterwards, so I stumbled into a random cafe on the way to the venue. Turned out it was a very nice one, where due to its nice interiour I managed to reflect on life, 42 and all the rest almost immediatly. A totally unexpected but needed break. I wont say more here, because the thoughts and memories are really mostly relevant for me, but I'm really happy I found that space. DebConf8 and this meeting both were really fun, but I really didnt have a minute to reflect things. 30 minutes to do that is definitly not enough, but it was a good start. Now I just need to find another opportunity to continue with it. I hope this will happen before the next Extremadura meeting ;-)

Otavio has updated kernel-wedge in SVN to 2.6.26, so I updated ARM and MIPS today. The udebs built after minor modifications and I can also build installer images after having fixed some bugs in the build process. I tested a 2.6.26 based image on the QNAP TS-409 (armel) as well as in QEMU (mipsel). 2.6.26 will bring major improvements on ARM. Orion support is much better and our 2.6.26 has a number of patches from Marvell that help with performance on Orion. Our 2.6.26 also has Riku Voipio's LED driver for Thecus N2100 which has been accepted for the 2.6.27 mainline kernel. I haven't actually uploaded the udebs yet because I'm waiting for the go-ahead as well as for the new version of the 2.6.26 kernel package to build. But at least we're getting closer to having 2.6.26 as the kernel for lenny.

Netgear has jumped the bandwagon and released Open Source Wireless-G Router (WGR614L). Like the earlier Linksys WRT54GL, it's an existing model with a Linux "L" added to end. It does not really add any hardware to make it community friendly, the "open source" part feels like just a marketing gimmick.

With just a couple of small features, these devices could really become community friendly:

• Serial port. A kingdom for a router or NAS with a proper serial port! Or at least a pre-solder the serial headers and provide a cable with a TTL shifter.
  
• Unbrickable bootloader. Alternatively, a relatively hard to brick bootloader like Linksys NSLU-2 has.
  
• Mainlined kernel. No "Linux 2.4.22 + binary drivers" crap, like this netgear device.
  
• Widespread availability. The community is around the world.
  
• Documentation.
  

Not as necessary, but nice to have features for a community-oriented product:

• JTAG. So one gets to unbrick it in case bootloader went bonkers. Also allows the community to develop the bootloader.
  
• Extensibility. Just adding a USB port gives any device huge amount of extra possible uses. A SD slot would give loads of storage space. etc..
  
• Contacts with engineers and developers from the manufacturer. Don't just market to the community, be part of the community :)
  

You know what the problem is? Webbrowser developers think they're developing the most important application for any computer. -Wouter

Weeelll.. Looking at the the long posts you and others on planet.d.o have written about a browser, one might get the opposite conclusion :) Considering the amount of work and daily business (online banks, shops, news, other services), browser is the most important application after email - and even for email many people use a browser...

Users are good at noticing usability problems. However, their proposed solutions are usually unreliable.

I'm just as annoyed as the next planet writer about the new self-signed SSL dance of FF3. But I do not pretend to know the correct solution. When dealing with security issues, knee-jerk fixes can lead to disasters. Likewise in UI design, the first idea that gets into mind probably isn't the best one.

While I have your Attention, one of the most interesting ARM projects at the moment: beagleboard . There is _huge_ variety of ARM developer boards available, but this one has a couple of really interesting bits

• Powered by OMAP 3530, a 600MHz ARM Cortex A8 + kitchen sink chip. Most boards are either expensive or have a "bottom-of-line" cpu.
  
• Didn't I complain that TI isn't open enough? Well, since then TI now has released thousands of pages documentation for OMAP3, made omap 35xx available or purchase for anyone, and is even working to get DSP and 3D bits of OMAP3 available. And they go further - beagleboard documentation (link at bottom of elinux wikipage for boeagleboard) has everything including schematics.